The invention relates generally to computer systems and deals more particularly with management of shared, heterogeneous files for access by heterogeneous clients.
Various file systems are known today, each with a unique set of file management rules. Known file systems include the Shared File System within IBM VM/ESA operating system and a UNIX (.TM. of Bell Laboratories) file system, an IBM AIX file system. The file management system defines rules for atomicity of requests, data filing sharing and access concurrency, data change consistency, etc.
"Atomicity of requests" relates to when updates are committed or rolled-back. "Commitment" of updates means to make them permanent such as by writing the updates to permanent storage. A rollback causes temporary information kept for update request processing to be deleted because there will be no permanent storage update. In some file systems, such as those which are POSIX compliant, after each user update request is completed, the update is automatically committed if successful or rolled back if unsuccessful regardless of whether the user will soon make related updates. Thus, each update request is atomic. In other file systems, such as the Shared File System, the file system may not commit or rollback an update request until specifically requested by the user. Moreover, the user can make a group of related, sequential update requests to one or more files in a "work unit", and defer the decision/request to commit or rollback until determining the outcome of all the update requests. Typically, the user will request commit if all the related update requests are successful and request rollback of all the update requests if any one was not successful. Thus, the work unit comprising the group of related updates is "atomic".
"Data filing sharing and access concurrency" relates to control of the number and types of concurrent access that are permitted for a file or data block. For example, some file systems permit for a file or part of a file, multiple concurrent readers with multiple concurrent writers while others allow multiple concurrent readers with a single writer. Other file systems permit multiple concurrent writers of a file as long as the concurrent writers are not concurrently writing to the same part of a file.
"Data change consistency" relates to control of when updates are presented to other clients who are currently reading or will subsequently read a file which has been updated. For example, some file systems will not present any file updates to a concurrent reader until the reader closes the file and subsequently requests to open the file again. Other filing systems, will present file updates to concurrent readers as soon as these updates are committed.
There are many other file management rules that are specific to each file system such as authorization rules, directory structures, locking, granularity of access, etc.
Each file system may also have a unique application program interface (API). The API for a file system includes the set of requests or operations that are used by applications, human operators, or by the operating system on behalf of applications and human operators, to communicate requests to the file system. The API also comprises the rules or semantics of behavior of the file system, i.e., the effects of various file system requests on objects in a file system repository. While the semantics may differ significantly between different file systems, the basic requests/operations may be similar and include open, read, write, close, query object status, etc.
Some computer systems utilize two or more file systems with different APIs and different file management rules. Some users, such as an administrator, may require access to different file systems and the access to the different filing systems may be concurrent and involve related work requests. According to the prior art, the administrator used different APIs for the different, respective file systems, and each file system enforced its own rules independent of the other file system. This created two problems. First, the administrator was required to know both APIs and utilize the proper API for each request. Second, for related work requests involving the different file systems, the file management rules of the different file systems may yield a result that violates the file management rules of one of the file systems. In addition, it is advantageous in many cases for multiple file systems to share a common data repository, such repository comprising a file server environment and permanent storage for file system objects and data. When file systems have a common repository, it is even more compelling that they have a single set of administrative operations for managing that common repository, i.e. a single API to the file server that hosts the multiple file system repository.
Accordingly, a general object of the present invention is to provide a file management system with a common API for accessing two different file systems and with controls to ensure that the rules of each files system are not violated.